Combining Static Analysis and Model Checking for Software Analysis 


Guillaume Brat 

Kestrel/NASA Ames Research Center 
Moffett Field, CA 94035, USA 
brat@email.arc.nasa.gov 


Abstract 

We present an iterative technique in which model check- 
ing and static analysis are combined to verify large software 
systems. The role of the static analysis is to compute partial 
order information which the model checker uses to reduce 
the state space. During exploration , the model checker also 
computes aliasing information that it gives to the static an- 
alyzer which can then refine its analysis. The result of this 
refined analysis is then fed back to the model checker which 
updates its partial order reduction. At each step of this it- 
erative process, the static analysis computes optimistic in- 
formation which results in an unsafe reduction of the state 
space. However, we show that the process converges to a 
fixed point at which time the partial order information is 
safe and the whole state space is explored. 


1 Introduction 

In industrial settings, software verification consists al- 
most entirely of testing. Formal analysis, be it based on 
static analysis or model checking, is not considered practi- 
cal for software applications. Fortunately, this situation is 
slowly changing and more resources are devoted to improv- 
ing the practicality of such analysis tools. For example, the 
Java PathFinder (JPF) model checker has been applied to 
the verification of critical avionics software [2, 11, 13]. 

JPF is a model checker which operates on principles sim- 
ilar to the SPIN model checker [7], i.e., given a closed envi- 
ronment for software, it performs a systematic exploration 
of the state space of the program by executing it. Therefore, 
JPF has to deal with issues such as generating an environ- 
ment to close a system, deriving finite models from infinite 
state spaces, and curbing the state explosion problem (so 
that exhaustive exploration can be performed). This work 
focuses on alleviating the state explosion problem (i.e., the 
model checker runs out of memory before it can explore the 
whole state space) by using partial order reduction, which 
eliminates the exploration of redundant paths due to the in- 
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terf aving of independent transitions. 

JPF relies on abstraction and static analysis to reduce 
the dze of state spaces. Abstraction is used prior to model 
checking; it generates a smaller program (meaning that it 
yields a smaller state space than the original program) that 
is a safe (it preserves the behaviors that are relevant to the 
proj erty under consideration) approximation of the original 
program. Static analysis is also used prior to model check- 
ing io slice the original program [6] (yielding a smaller, safe 
prog ram), and also, compute information needed to perform 
parti al order reduction during model checking. JPF has the 
folk wing important (for this work) characteristics: 

• it is an explicit- state model checker for Java programs, 
i.e., it uses a custom Java virtual machine to explore 
states in a DFS manner and verify properties; 

• it prunes on-the-fly the state space using partial order 
reduction on safe transitions; 

• it relies on static analysis to compute safe transitions. 

This paper focuses on partial order reduction, and the 
interactions between static analysis and model checking. 
Sinci static analysis is used prior to model checking, partial 
order analysis is subject to the following limitations of static 
analysis: no knowledge of the values taken by variables at 
run time (even though we make limited use of symbolic 
evalu ition through the Bandera toolset [4]), approximations 
inherent to using the traditional dataflow framework (e.g., 
widening or k-limiting), and, the fact that the precision of 
static analysis is directly conditioned by the precision of its 
aliasing algorithm. Unfortunately, most practical alias anal- 
yses ; re quite imprecise. JPF however can compute precise 
aliasing since it explores the state space by executing the 
progr im under all possible interleavings. Therefore, our 
driving idea is to research how we can interface the static 
analyzer and the model checker so that we can take advan- 
tage of one’s strengths to cancel the other’s weaknesses. 

In this paper, we show that the static analyzer and the 
mode! checker can operate concurrently and reduce signif- 
icant! ;/ the size of the explored state space. The static an- 



alyzer can use dynamic information (i.e., alias sets) com- 
puted by JPF during state exploration and statically com- 
pute partial order information that JPF can use to prune the 
state space. The aliasing information given to the static an- 
alyzer is a subset of the real alias set; therefore, static anal- 
ysis may produce incorrect information about safe state- 
ment which JPF cannot trust to definitely discard execution 
paths. However, this information can be used to pick paths 
(that are not discarded by the current partial order infor- 
mation) during state exploration. As JPF covers more of 
the state space, it computes a safer alias set (i.e., closer to 
the real alias set), and in turn, the partial order information 
computed by the static analyzer is safer (i.e., more relevant 
paths get included in the exploration). Eventually, this iter- 
ative analysis reaches a fixed point (the alias set is the com- 
plete alias set for the current environment), and, the model 
checker knows exactly what paths can safely be discarded. 
The innovativeness of our work is twofold: 

1. we use static analysis and model checking concur- 
rently to increase their precision, and 

2. we perform a safe analysis by computing (less and 
less) unsafe information. 

The paper is organized as follows. Section 2 describes 
static analysis and partial order reduction. In Section 3, we 
formalize our approach and prove that it yields safe solu- 
tions. We then describe an example, discuss some practical 
considerations, and present our conclusions. 

The rest of the paper uses the following notations. State- 
ments (also referred to as transitions) are denoted by lower 
case letters such as n, . . .. The set of all statements is 
called T. The thread of execution for a given statement n is 
given by 9(n). The state of the system is usually referenced 
by the lower case letter s. The state reached from a state s 
after statement n has been executed is denoted by n(s). The 
set of all possible states is called 5. The set enabled{s) rep- 
resents the set of statements that can be executed at state s, 
i.e., the transitions that are enabled in state s. For a given 
statement n, def(n) (re f(n)) is the set of variables defined 
(used) at n. 

2 Static Analysis in JPF 

Java PathFinder [2, 11, 13] is an explicit state model 
checker that takes compiled Java programs (i.e., byte code 
class-files) and analyzes all paths through the program 
for deadlock, assertion violations and linear time temporal 
logic (LTL) properties. JPF is built on a custom Java Virtual 
Machine (JVM) and therefore does not require any transla- 
tion to an existing model checker’s input notation. Since 
JPF is custom-made for Java model checking, it allows an 
aggressive attack on the state-explosion problem inherent in 


mo >t complex Java programs. Importantly, the JPF model 
checker has full control over which (Java) statements to ex- 
ecu te in every state, and moreover, has the complete state of 
the JVM at its disposal at all times during execution. These 
two characteristics allows the implementation of the con- 
cepts in this paper: partial-order reductions (only execute 
cer ain transitions in each state) and calculation of alias in- 
formation (present in the data-portion of the JVM state). 

2.1 Partial Order Reduction 

Vo perform a correct verification of an asynchronous sys- 
tem (in our case, a multi-threaded Java program), the model 
checker has to explore all possible interleavings of concur- 
rent transitions (i.e., concurrent statements) in the system. 
Uni ortunately, the interleaving model yields a combinato- 
rial explosion in the number of states that need to be ex- 
plored. The goal of partial order reduction is to use the 
commutativity of concurrent transitions to reduce the state 
spat e that needs to be explored by a model checker. 

I or example, a system consisting of two threads with 
three transitions each, such that transitions in one thread 
are ndependent from transitions in other threads, yields a 
spat e consisting of 16 states and up to 20 different paths. 
Hoy ever, any such two paths differ by at most nine commu- 
tati( ns of transitions (on different threads). If the property 
chet ked by the model checker on this system is not sensi- 
tive to those transitions, then the state space can be reduced 
to o lly one path, i.e., seven states. 

/• s described in [3], two transitions are independent if the 
exec ution of one does not disable the other (and vice versa) 
(encbledness condition) and they result in the same state re- 
gart less of their execution order (commutativity condition). 

Definition 1 two transitions n and m are independent at a 
give i state s if the following two conditions are satisfied: 

1. n,m E enabled(s) enabled(m(s)) 

2. n,m E enabled(s) => n(m(s)) = m(n(s )) 

The e conditions define an independence relation between 
pair of transitions (statements) that is symmetric and anti- 
refiedve. In [8], Holzmann and Peled extend this definition 
of ir dependence with the concept of global independence. 

Definition 2 Two transitions n and m are globally inde- 
pencent if and only if they are independent in every state 
whe e they are simultaneously enabled. 

We need two other conditions to perform path elimina- 
tion ising independence. First, transitions have to be invis- 
ible with respect to the checked property, i.e, its execution 
from any state does not change the value of the proposi- 
tions 1 variables in the property. Second, eliminating a path 



should not eliminate another path that branched out of one 
of the intermediary states. 

Partial order reduction is usually implemented using the 
concept of ample sets. An ample set at state 5 (denoted 
ample(s)) is a subset of enabled(s). When operating in 
a partial order reduction mode, the model checker will ex- 
plore only paths, from a given state, that start with transi- 
tions in the ample set rather than the enabled set. In other 
words, given a state s, partial order reduction results in 
the elimination of all the paths starting with transitions in 
enabled{s) \ ample(s). According to [3], the following 
conditions yield a correct ample set (5 is a given state): 

CO ample(s) — 0 O enabled(s) = 0; 

Cl along every path in the full state graph that starts at 
s , the following condition holds: a transition that is 
dependent on a transition in ample(s) cannot be exe- 
cuted without a transition in ample(s) occurring first; 

C2 if 5 is not fully expanded, then every transition in 
ample(s) is invisible; and, 

C3 a cycle is not allowed if it contains a state in which 
some transition is enabled but is never included in 
ample(s) for any state s on the cycle. 

Note that Cl implies that the transitions in enabled{s) \ 
ample(s) are independent of those in ample(s). 

Verifying condition Cl is as hard as checking reachabil- 
ity for the full state space (see Theorem 11, page 154 of [3]). 
Moreover, the full state space is not available when ample 
sets are computed during on-the-fly model checking as it 
is the case in JPF. Therefore, practical implementations of 
partial order reduction need to use conditions that are easier 
to check, even if they yield less reduction [3]. 

JPF relies on another concept based on safe transitions 
[8]. In essence, a transition is safe if it is independent on 
any transition of any other thread. A partial order reduction 
scheme that uses only safe transitions in the ample set is 
guaranteed to yield correct results. 

Definition 3 Given a property P, statement n is safe if it is 
invisible with respect to P and globally independent from 
any m such that 9{n) 8(m). 

Practically, at any given state s, JPF looks for a safe transi- 
tion in enabled(s) (the set of enabled transitions at s ). If it 
finds a safe transition, say t, JPF executes it and explores the 
graph it creates. During backtracking, JPF ignores the paths 
originated in the other transitions (enabled(s) \ {£}). If it 
does not find any safe transition in the enabled set, all transi- 
tions are explored. In other words, the ample set (ample(s)) 
is either the full enabled set (enabled(s)) or a singleton con- 
taining one of the safe transitions in enabled(s). Contrary 
to SPIN, JPF relies on a static analyzer to perform the de- 
pendence analysis needed to identify safe statements. 


2.1 Static Analysis 

rhis section describes how JPF uses static analysis to 
CO; npute partial order information. We designed our analy- 
sis based on the dependences defined in the Bandera toolset 
[4] Hatcliff et al defined six types of dependences [6]. 
Th :re are three intra-thread dependences which are usually 
found in sequential programs, namely: data , control and 
dix irgence dependences. Since these dependences relate 
sta ements within the same thread, they cannot be used to 
ide itify independent statements (see page 157 of [3]). 

fiatcliff et al also define three types of dependences 
(in erference, synchronization , and ready dependences) that 
capture concurrency issues. The interference dependence 
captures the fact that shared variables can escape the scope 
of 1 given thread. We give the formal definition of inter- 
ference dependence because it is useful when it comes to 
computing partial order information. 

Dei inition 4 A statement n is interference-dependent on a 
sta ementm if 

1 9{n) 9(m), and 

2 def(m) H refin ) ± 0. 

No e that def(m) and re /(n) need to take into account the 
pos able presence of aliases. Second, it is obvious that, if 
n i interference-dependent on m, then n and m are not 
globally independent (they do not commute) with respect 
to 1 artial order reduction. So, computing interference de- 
pen fences gives important information about independence 
with regard to partial order reduction. However, interfer- 
enc : dependence is not quite restrictive enough to identify 
safe statements. Therefore, we take a conservative approach 
and consider that any statement defining or using (possibly 
via m alias) a shared variable is unsafe. Our problem then 
becomes analyzing statically a program to identify shared 
vari lbles. This requires alias analysis. 

Toth the synchronization and ready dependence are ir- 
rele /ant to our discussion on partial order reduction. Syn- 
chr< nization dependence exists to make sure that the mon- 
itor enclosing a statement that is in the slice are also in 
the dice. Since the statements involved in synchronization 
are n the same thread, they are already considered depen- 
den with regard to partial order reduction, and we do not 
need to compute if statements are synchronization depen- 
den . The ready dependence states that a statement n is 
reac y-dependent on a statement m if rn* s failure to com- 
plet * can make 9{n) block before reaching or completing 
n. According to this definition, the execution of m does not 
disa fie n; quite the contrary, it enables n. Therefore, ready 
dependence is irrelevant to the notion of dependence with 
regard to partial order reduction. 



If neither synchronization nor ready dependences are 
useful to provide information about independence with re- 
gard to partial order reduction, we still need to study the 
synchronization means in Java and analyze their impact on 
statement independence. For that, we take a closer look 
at the synchronization commands identified in [6]: namely, 
enter-monitor , exit-monitor , wait, notify , and notify -all. The 
first command ( enter-monitor ) is the only one that can dis- 
able statements on different threads. Indeed, the execution 
of enter-monitor prevents other threads to access the lock, 
potentially disabling transitions on those threads (note that 
it disables only statements that are attempting to acquire the 
same lock; once again it is a shared object problem). The 
exit-monitor , notify , and notify-all commands release locks; 
therefore, without considering possible exception problems, 
these commands do not disable other statements; they rather 
enable some. Finally, the wait command does block the ex- 
ecution of some statements, but only on the same thread, 
which means that it can block only statements that have al- 
ready been deemed dependent; therefore, we do not need to 
pay special attention to wait commands. 

The static analyzer does not really compute what state- 
ments are safe. It identifies unsafe statements, and then 
mark the other statements as safe. Here is the formal defi- 
nition of an unsafe statement: 

Theorem 1 A statement n is unsafe if 

1. n is interference dependent on any other statement, 

2. n is an enter-monitor statement , or 

3. n is an invoke statement on a synchronized method. 

Conditions 2 and 3 are stronger that they need to be. An 
enter-monitor statement is unsafe only if there is another 
enter-monitor statement on another thread attempting to 
grab the same lock. Condition 2 takes a conservative ap- 
proach and mark any enter-monitor statement as unsafe. 
Similarly, condition 3 takes a conservative approach by 
marking all invocations of synchronized methods as unsafe. 

2.3 Implementation 

Partial order reduction is performed on-the-fly by JPF 
based on information computed by the static analyzer. As 
illustrated in Figure I, in the current implementation, static 
analysis is done before model checking. The static analyzer 
identifies a set of safe statements, which JPF uses to elim- 
inate redundant paths. The static analyzer is run only once 
(before any run of the model checker) and therefore it pro- 
vides conservative results; it only computes a subset of the 
ideal set of safe statements. This guarantees that all inter- 
leavings that can affect the result of the verification process 
are explored by JPF. The precision of the analysis directly 


aff xts the number of paths that JPF can ignore. Therefore, 
ap} roximations made by the static analyzer have a direct 
imj >act on the level of reduction achieved by JPF. 



Figure 1. One-time partial order reduction. 

Partial order analysis depends on aliasing and call graph 
analyses; hence, it suffers from the approximation intro- 
duced by those analyses. Unfortunately, aliasing analysis is 
a complex problem [10]. For example, it has problems han- 
dlin g possibly infinite data structures. Practical algorithms 
rely on k-limiting schemes that differentiate aliases in lists 
onh up to a depth of A; [10]. Moreover, scalable algorithms 
typically do not differentiate between different calling con- 
text [1, 12]. This leads us to believe that only limited par- 
tial >rder reduction can be achieved by using static analysis 
as a pre-processing step. 

C ur driving principle is based on two observations. First, 
JPF can compute precise aliasing (and call graph) informa- 
tion while the static analyzer can only compute approxi- 
mate aliasing information. Therefore, JPF should be the one 
commuting the aliasing information. Second, JPF lacks a 
global view of the synchronization in the system; it usually 
considers only one path of execution at a time and it does 
not r ealize the synchronization problems until it bumps into 
then . The static analyzer has a more abstract view of the 
sysh m, and given the proper aliasing information, it does 
a go id job at computing partial order information. There- 
fore. it should be the one computing the independence sets. 
Therefore, it seems that, by working on different aspects of 
the problem, they could help each other and do a better job 
than they do now. This paradigm is illustrated in Figure 2. 



Figure 2. Iterative partial order reduction. 

Theoretically, this paradigm is attractive, but, practically, 
it seems to be only realizable at the expense of safety (i.e., 










the verification is optimistic and does not offer guarantees 
even if it terminates). Indeed, JPF can only compute par- 
tial alias sets as it explores the state space. Only when 
it has completely explored the state space can it compute 
precise alias sets. Therefore, it seems that, in our scheme, 
static analysis would always be based on unsafe alias sets, 
and hence, produce only overly optimistic sets of safe state- 
ments. This implies that JPF could potentially ignore rel- 
evant paths, and therefore, miss some errors. Fortunately, 
this is not so as we prove in the next section. 

At each new iteration, JPF adds new aliases to the 
alias sets it computed during previous iterations. These 
new aliases may lead the static analyzer to re-classify safe 
statements as unsafe (but never unsafe statements as safe). 
Therefore, at each new iteration, the set of safe statements is 
a subset of the safe statements at previous iterations. Each 
time a statement is re-classified from safe to unsafe, it forces 
JPF to consider additional paths. The iteration process starts 
with no alias sets (or one resulting from a must-alias anal- 
ysis) and optimistic sets of safe statements. The process 
goes on until JPF has safely identified all the aliases in the 
program. At that point, JPF gives an exact alias set to the 
static analyzer, which in turn can compute an exact set of 
safe statements. That set is then used by JPF to identify 
exactly all the relevant remaining paths. The overall verifi- 
cation process then finishes once JPF has covered all rele- 
vant paths. All of this is valid because JPF never completely 
discards a path until the whole verification process is over. 

The innovative aspect of our method is that it performs 
an overall safe analysis out of iterative unsafe analysis steps. 
Moreover if no approximations are introduced by the static 
analyzer when computing the set of safe statements, then it 
results in an optimal reduction of the state space. The state 
spaces explored by JPF during each iteration (besides the 
last one) are only partial state spaces. Therefore, stopping 
at these stages could yield incorrect results. The overall 
process converges towards an optimal (in terms of partial 
order reduction) state space. 

In the next section, we describe a framework that formal- 
izes this approach. We then use it to prove the correctness 
of this approach. In particular, we prove that the iteration 
process cannot falsely detect that an alias set is complete 
(which could cause an early termination of the state explo- 
ration and hence yield incorrect results). 

3 Formal Framework 

3.1 Aliasing 

In this section, we define aliasing and establish results on 
the alias analysis done by JPF. Formally, an alias at program 
point t is a pair (u, v) of references ((u, v) E R 2 where R is 
the set of references in the program) that point to the same 


stc e location. In other words, u and v give access to the 
same object. We can represent all aliases in a program as a 
ma oping of program points to alias sets as follows: 

A: T 2 RxR 

t t-+ {(u, v) E R 2 } 

where A(t) represents the set of aliases holding at program 
poi nt t . We define A as the set of all possible alias mapping 
for a given program. In the rest of the paper, we will refer 
to . 1 E A as the alias set of the program. We also define a 
nat oral partial order on A as follows: 

V(A, B) E A : A C B & (Vt E T : A(t) C B(t)). 

In he presence of dynamic information about finite pro- 
grams, A is finite. The number of references is bounded, 
and therefore, there is a finite number of alias combinations. 

We assume that at any given time during the analysis, we 
can determine the set of states S e that have been explored by 
JPf We also assume that JPF can reliably compute the set 
of aliases holding at any given state. Let f a (fa : S -4 *4) 
be the function that allows JPF to extract aliases from a set 
of e xplored states. Thus, 

fa(S 6 ) = A 

wht re S e is the set of explored states and A is the set of 
alia >es for the current set of explored states. It is obvious 
that f a is monotonically increasing. 

V(X, Y) ES 2 :ICf=> f a (X) C f a (Y) (1) 

Indt ed, exploring more states does not eliminate aliases, it 
onb adds more aliases. 

3.2 Safe Statement Analysis 

V/e assume that the static analyzer has a consistent 
means of computing the set of safe statements given an alias 
set. Let f 8 {fs : A -» T) be such a function. Thus, 

fs(A)=I 

whe e A is the current set of aliases in the program and I is 
the i et of safe (independent) statements that can be inferred 
given A. Obviously, f s is monotonically decreasing. 

V(X, f)Ed 2 :ICF^ f s (Y) C f s (X) (2) 

Add ng an alias may create a new dependence among state- 
men s, but it does not remove any. Therefore, it can only 
char ge a safe statement into an unsafe statement and can 
never change an unsafe statement into a safe statement. 

F irthermore, let f T be the function (f r : T — > S) that, 
give i a set I of safe statements, can compute the largest set 
of slates S M = f r (I) that can be explored by JPF. It is 
obvi >us that, at any given time, the set of state explored by 
JPF say S e ) is a subset of S M . 

s e c s M c s 



3.3 Fixed Point Analysis 

The analysis uses an iterative process which sees the 
static analyzer compute independence sets and JPF bounds 
on state exploration and alias sets. The process goes as fol- 
lows (note: indices relate to iterations): 

1. given an alias set Ak- 1 , the static analyzer computes 
an independence set = f s (Ak-i) while JPF is ex- 
ploring a confined state space (5|_ x C S£L x ); 

2. then JPF uses Ik to limit its exploration to a new con- 
fined state space (S™ = f r (h)) by performing partial 
order reduction; 

3. JPF computes a set of aliases Ak given the state space 
S € k it has explored (A k = fa(S k ) and S k C S k T )\ 

4. the process goes back to Step 1 unless a fixed point has 
been reached (Ak+i = Ak ). 

To show that a fixed point is reached, we define C = 
(A x T x 5 x S) where any c £ <7 consists of an alias 
set, a set of safe statements, and confined and explored state 
spaces. We also define a partial order relation C over C : 

Vci = (Ax,Ii,S^ , Si) y C2 — [A2,h^S^ ,5|) £ (7 : 

Ci C C2 ^ 

(Ai c A 2 ) a (h D I 2 ) A (Sf c a (5 x e c S|) 

The fact that □ defines a partial order derives directly from 
the fact that C is a partial order relation. Therefore, ((7, □) 
is a partial ordered set (or poset). It is also easy to show that 

Lemma 1 ((7, C) is a complete lattice . 

Proof: First, note that C is finite because T, 5, and A are 
finite. Therefore, we only have to show that the supremal 
(sup Y) of a set Y C C is in C (and similarly for the infimal 
of Y, inf Y). This is trivial since sup C = ( A , 0, 5, 5) £ C 
and inf (7 = (0, T, 0, 0 ) £ <7. 

■ 

We now define a function / (/ : C — > C) that summa- 
rizes the effects of an iteration. Thus, 

Vc= (AJ,S M ,S e ) £C: 
f{c) = (5 o fa(S e ), fs{A),fs O fr(A), s e ) 

It is also trivial to show that, for any iteration k , 

C A t , I t , S^, St ) = 

and that, using (1) and (2), / is monotonically “increasing”. 
V(c l5 c 2 ) £ C : ci □ c 2 ^ /(ci) C /(c 2 ) (3) 


Theorem 2 / has a supremal fixed point 

Proof: All we have to show is that 

"* / is a monotone function (see (3)) 

/ is defined over a complete lattice ((7, C) (see Lemma 
1). Then, according to Theorem 2.1 in [9], / admits a 
supremal fixed point. 


At his point, we have shown that our iterative verification 
process will converge to a fixed point. We still have to show 
tha this fixed point corresponds to a correct analysis. 

Theorem 3 After termination of the iterative process , all 
relt vant paths have been explored. 

Proof: Let P(S) be the set of paths in the full state space 5. 
Let P(Sa) be the set of paths in the explored states space. 
Let T be the set of all possible transitions. Let s(p) be a 
fun tion that returns the final state of a path p. 

Assume that there exist paths that should have been ex- 
plor ed but have been discarded by JPF based on the partial 
ordt r information given by the static analyzer. Let p be the 
first such path that could have been encountered by JPF. 

P eP(S)\P(S A ). 

Let p* £ P(Sa) be the explored path that “caused” p to 
be ciscarded. Then, there exist two transitions t and t ! and 
thre • sub-paths pi, j> 2 , andp 2 su °b that 

• p =Pi-t.p 2 , 

• p 1 = pi.t'. p' 2 , 

• t,t' C enable(s(pi)) y and 

• t! was misclassified as safe. 

If t f s not safe, then either f is visible by the property being 
chec Hied or it is not globally independent. 

It is not possible for t f to be visible by the property be- 
cause it would imply that an alias at t f had been missed even 
though t! was executed by JPF; this violates the assumption 
that ilias discovery on states visited by JPF is correct. 

Then, t f must not be globally independent. Moreover, 
since p should have been explored, it means that t and t* are 
not independent at state s(pl). This implies that t and t! 
acce s a shared variable (or lock) through aliases and that at 
least one of these aliases is never uncovered during the anal- 
ysis. However, such aliases result from the execution of the 
last t ansition in pi (i.e., the transition preceeding t in p and 
t‘ in , /). Since JPF has executed that transition, these aliases 
woul 1 have been found by JPF (again, using the assump- 
tion mat alias discovery on states visited by JPF is correct). 


Therefore, we can show that 



Therefore, there are no aliases accessing a shared variable 
from t and t\ and t! is globally independent. 

Therefore, p was rightly discarded by JPF. We can repeat 
this reasoning for every (wrongly discarded) path and prove 
that all the relevant paths have been explored by JPF. 


4 Example 


The example in Figure 3 is a simple multi-threaded pro- 
gram that exhibits a subtle deadlock due to incorrect initial- 
ization of variables. Essentially the deadlock is due to the 
count variables in Taskl and Task2 not being initialized to 
zero - the important statements that would need to be inter- 
leaved in order to find this error are the assignments to the 
count variables just prior to the while loop in each thread 
(i.e., statements labeled u\ and u 2 in Figure 3). 


class Main { 

static void main(String[] args) { 
Event new_evl = new Event(); 
Event new_ev2 = new Event(); 
Taskl taskl = 

new Taskl (new_evl,new_ev2); 
Task2 task2 = 

new Task2(new^evl,newjev2); 

taskl. startO; 
task2.start0; 

} 

} 

class Taskl extends Thread { 

Event event l,event2; 
int count = 0; 

Taskl (Event e 1 , Event e2) { 
this.eventl = el; 
this.event2 = e2; 

this. startO; 

} 

void runO { 

m : count = eventl. count; 
while(true) { 

event l.wait_for_event(count); 
count = eventl .count; 
event2.signal_event(); 

} 

} 

} 


class Event { 
int count = 0; 
synchronized void 

wait_for.event(int rcount) { 
if (rcount = count) 
try {waitO;} 

catch(InterruptedException e){}; 

synchronized void signal_event() { 
count = (count + 1) % 3; 
notify All(); 

} 

} 

class Task2 extends Thread { 

Event eventl ,event2; 
int count = 0; 

Task2(Event el , Event e2) { 
this.eventl = el ; 
this.event2 = e2; 
this.startO; 

} 

void runO { 

U 2 i count = event2.count; 
while(true) { 

event l .signal jevent(); 
event2. wai t _for_e vent(count); 
count = event2.count; 

} 

} 

} 


Figure 3. Java program with deadlock. 


During the first iteration, the static analyzer does not 
have any aliasing information. Let us examine the class 
Taskl. Even though the analyzer can determine that 
the fields eventl and event! are probably aliased to ob- 
jects on different threads, it has no concrete proof that it 
is happening (because it has no alias information at this 
point). Therefore, the analyzer has no choice but to mark 
all the statements dealing with those variables as safe, ex- 
cept for the statements invoking the synchronized methods 
wait.f or .event and signal -event. In these cases, the an- 
alyzer can infer that these invocations will ask for locks 


(e\ en though it does not know which locks) and we mark 
sue h calls as unsafe (without checking what object is used 
as i lock). A similar analysis is done for the class Task 2. 
All statements in class Event are marked as safe (and will 
remain so since no aliases can be generated in the Event 
cla ,s). All statements in class Main are marked as safe. 

During the first exploration done by JPF, the follow- 
ing aliases (among others) will be uncovered. The refer- 
ences Main.new.evl, Taskl. eventl, and Task2.eventl 
will be aliased when taskl and task 2 start running. Sim- 
ilar y, the references Main.new.ev2, Taskl. event!, and 
Ta ;k!.event 2 will be aliased when task 1 and task! start 
run ling. Since the statements u\ and u 2 (in bold in the fig- 
ure have been marked as safe, they are not interleaved and 
JPF does not find the deadlock. Still, JPF passes important 
alia > information to the static analyzer. 

During the second iteration, some alias information, in- 
cluding the aliases concerning the fields event 1 and event 2 
in both Taskl and Task! will be known to the static ana- 
lyz< r. Using this information, the analyzer can now mark 
as i-nsafe any statement accessing the fields event 1 and 
eve it! in both Taskl and Task 2 (including statements u\ 
and u 2 ). This results in only one safe statement in each of 
the hread: the condition of the while loops. 

This new information is then communicated to JPF 
whi 'h realizes it needs to take into account some additional 
interleaving. This results in JPF interleaving statements u\ 
and u >2 and in the deadlock being found. 



no p.o.r. 

p.o.r. 

ui,u 2 safe 

p.o.r 

U\, u 2 unsafe 

States 

866 

339 

432 

Transitions 

1489 

459 

632 

deadlock 

found 

not found 

found 


Figure 4. State space reduction figures. 


Tible 4 shows the results of running JPF without partial 
order reduction and with different information about safe 
statements. Column 1 shows the results when JPF does not 
use tny partial order reduction. Column 2 shows the re- 
sults obtained by JPF with partial order reduction using an 
over y optimistic set of safe statements. Column 3 shows 
the results obtained by JPF with partial order reduction us- 
ing i correct set of safe statements. Since the example is 
quite small, JPF can find the deadlock without partial or- 
der reduction, but, to do so, it has to visit twice as many 
state > as when it performs partial order reduction with the 
com ct safe statements. When the information about safe 
state nents is incorrect (as in the first iteration) the deadlock 
is net found. But the discovery of aliases by JPF leads to a 
com et set of safe statements, and, JPF eventually finds the 
dead ock after visiting roughly 100 more states. 



5 Practical Considerations 

Our technique relies on the fact that JPF always finishes 
the exploration of a graph once it has started it. This is 
not true in general either; explicit state model checkers of- 
ten run out of memory before they can finish exploring the 
whole space. If it is the case, our iterative technique will 
perform an unsafe analysis. However, in its normal pro- 
cessing mode, JPF would have run out of memory anyway. 
So, the result of its analysis would be unsafe too. Therefore, 
our method does not do worse than the normal processing 
mode. We might even argue that it would cover a “more 
relevant” state space before it runs out of memory. 

A final important consideration is the fact that JPF, as 
most explicit-state model checkers, stops at the first error 
it finds and returns with an error trace (in JPF’s case, a 
full execution trace). Therefore, by constraining the model 
checker to stay within a confined state space (at each itera- 
tion), we restrict the possibility of the model checker to get 
lost in some uninteresting part of the state space. It would 
be interesting to extend the static analysis so that the model 
checker is guided towards critical areas first. 

6 Conclusion 

We have described an iterative process to perform soft- 
ware verification using static analysis and explicit-state 
model checking. Static analysis identifies safe statements 
which are used by the model checker to perform partial or- 
der reduction (thus increasing the chances of exhaustive ex- 
ploration). The model checker performs state exploration 
(using partial order reduction) and computes precise alias 
sets used by the static analyzer to identify safe statements. 
This work is innovative for the following reasons. 

• It describes a framework where static analysis and 
model checking work concurrently to improve the cov- 
erage and the precision of software verification; we are 
aware of only one other work [5] using model check- 
ing and static analysis concurrently; but it is based on 
abstract interpretation and abstract model checking. 

• It describes an iterative process that computes unsafe 
intermediate results until it converges to a safe result; 
traditional research ideas in static analysis and explicit- 
state model checking try to improve on safe solutions 
by reducing the impact of the approximations. 

• This method yields a solution that is much closer to the 
optimal solution (both in terms of aliasing and partial 
order reduction) than traditional methods. 

However, we pay the price of losing some of the generality 
in the results of the static analysis. Since we incorporate dy- 
namic information, the results of the static analysis cannot 


be re-used for different inputs (environment) of a program 
as it was the case in the traditional linear process. 

Our future plans are to improve the current implementa- 
tio i, to experiment with this technique on many more Java 
pn grams, and to define a rationale for the duration of the 
ite ation steps. Future improvements include the use of on- 
demand (or compositional) algorithms in the static analysis. 
We expect that, as we experiment with other Java programs, 
we might have to refine the distribution of work between 
the static analyzer and the model checker. We will also con- 
sid< .r other types of interactions between the model checker 
anc the static analyzer, and possibly other techniques. 
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